fix: use merge-base anchors for stale branch adoption#38
Conversation
Fix HACK-615 by teaching stack track to record a repairable restack anchor when adopting a branch whose parent has already moved. If the current parent tip is not an ancestor, track now stores the merge-base instead of unusable metadata.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c5d68c227c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if !ok || mergeBase == "" { | ||
| return "", fmt.Errorf("branch %q does not share a repairable merge base with parent %q; rebase it first or choose a different parent", branch, parent) | ||
| } | ||
|
|
||
| return mergeBase, nil |
There was a problem hiding this comment.
trackRestackAnchor currently accepts any git merge-base(parent, branch) result as a repairable anchor and stores it in LastParentHeadOID, but that is unsafe when the parent was rebased/force-pushed: the merge base may fall back to trunk, and runRestackPlan later calls git rebase --onto <parent> <anchor> <branch>, which replays old parent-only commits onto the child (not just child commits). This changes prior behavior from a hard stop on invalid anchors to silent history corruption in stale-adoption flows where the parent history was rewritten, so this fallback needs an additional safety check (or explicit refusal) before accepting the merge-base anchor.
Useful? React with 👍 / 👎.
Summary
Verification
stack restack --all, confirm the stored anchor moves from old parent base to new parent head